Subject: Agenda for DLSW-SIG meeting

From: "David Miller (254-5752)" <[email-masked]>
Date: Tue, 15 Jun 93 16:14:36 EDT

Since we only have 4 hours to discuss matters, I would like to
propose an agenda for the meeting:

  - 5 45 (+/-) minutes sessions

  - Session 1:  Flow Control
  - Session 2:  NT 2.1 Support
  - Session 3:  Capabilities Exchange
  - Session 4:  General discussion of technical matters not
      discussed in previous sessions
  - Session 5:  Charter discussion

For these sessions, I went through the function matrix and chose
the most popular items for discussion.  I did not include Ethernet
because the latest release of DLSW (shipping, as of this month,
within MPNP V1R1.1.2) has Ethernet support in it.  I expect the RFC
should be updated with how our Ethernet support works.  I did not
include the MIB because an SNA MIB is already being discussed in
another AIW session.

Comments??  Complaints??

David Miller

P.S.  If I do not hear anything, then this will be the agenda for the
meeting.

---

From: [email-masked]
Date: Wed, 16 Jun 93 07:40:03 PDT

David -

    In early May, I had volunteered to discuss SDLC-to-SDLC tunneling from 
    the perspective of cisco's STUN and DLSw.  That doesn't show up 
    anywhere in your list below.  I've included the corroborating email 
    at the end of this message.

    Also, I don't agree that the charter discussion should be last.  It
    is too important to "fall off the agenda".  It should be first with a
    time limit placed upon it.  Without a charter, this standardization
    effort is a farce.

Wayne Clark
cisco

>P.S.  If I do not hear anything, then this will be the agenda for the

*******
Email of May 6, 1993:

To: "Shannon Nix" <[email-masked]>
Cc: [email-masked]
Subject: Re: DLSw Matrix 
Date: Thu, 06 May 93 08:58:21 PDT
From: [email-masked]

Shannon-

>Please add MIB to Netlink's interest column.

    Done.

>
>Could someone explain what is meant by enhanced SDLC support?  The issues I 
>have heard to date include: 1) secondary as well as primary  2) group poll 
>as either a primary or secondary station.  What, in the current DLSw 
>specification, is precluding an implementor from supporting primary, 
>secondary or negotiable link station roles as well group poll of any 
>flavor?  These seem like implementation choices rather than DLSw 
>issues.

    I believe you are right ... SDLC (and other DLCs, for that matter)
    are merely implementation choices at the ends.  For SDLC on both
    ends, I don't believe there are any SSP extensions required. But
    we need to make sure so we can accommodate the SDLC-to-SDLC market
    so consider "SDLC support" a placeholder until we look at it in
    more detail.

    Since cisco was the original requester of this feature, I'll do the
    detailed examination of SSP using cisco's STUN (serial tunneling)
    as a requirement and report to the group at our meeting in June.
    If we determine that SSP can do SDLC-to-SDLC, then we should drop
    that feature from the matrix.

>
>The one possible implication, that I can see, would be in how the switches 
>handle the link station role negotiation in the XID3 exchange.  But we have 
>identified XID3 negotiation as a separate issue anyway.
>
>
>Just curious, 
>Shannon

-----------
Wayne Clark
cisco Systems, Inc.
[email-masked]
415/688-4627

*******
Email of May 11, 1993:

To: "Jim (J.) Cobban" <[email-masked]>
Cc: [email-masked], [email-masked],
        [email-masked]
Subject: Re: IBM DLSw activity 
Date: Tue, 11 May 93 09:41:03 PDT
From: [email-masked]

>>There was a question awhile back regarding TEST frames and SDLC.  The 6611 MP
>QP adapter
>>will reject a received TEST frame as a protocol violation.  Yes, use of the T
>EST
>>frame is architected;  however, it is never used.  Most devices (if not all) 
>do not
>>send/receive TEST frames on SDLC lines.
>>
>
>If taken literally this statement is totally wrong.  In fact I am not aware
>of a single IBM implementation of SDLC which does not send and receive TEST
>frames (except, obviously, the 6611).  I must assume that the word
>"unsolicited" was omitted by accident from the above statement.
>
>Since the current 6611 only supports the attachment of secondary stations
>then it is true that as long as the 6611 does not transmit a TEST frame, it
>should never receive a TEST frame.  However all devices which can be attached
>to a 6611 in this manner will correctly respond to a TEST frame if one is
>sent to them.  It could be perceived as a product limitation that the 6611
>does not provide this diagnostic test.  Since the 6611 is such a new product,
>and since it is being sold into a market which has not been characterized by
>the need to be able to manage large numbers of low-speed, low-quality lines it
>is understandeable that it omits a considerable part of the traditional
>diagnostic capabilities of SNA equipment.
>
>The discussion of TEST frames arose specifically in connection with SDLC to
>SDLC connections, and distinct from the requirement for support of T2.1.  It
>is therefore clear that the support which is requested here is specifically
>in relation to the 37xx NCP link level 2 test.  

[ *** remainder of Jim's response deleted *** ]

I agree with Jim's assessment.  SDLC TEST frames can't be ignored.

Cisco's SDLC-to-SDLC implementation in STUN (serial tunneling) treats
XID and TEST identically and handles each transparently when local
ack'd.  This means that they are merely passed through end-to-end in
all states without the routers trying to diddle with them.  Both TEST
and XID can happen at any time (e.g. non-negotiation XID3 exchange) and
only the SNA end systems care about their content.

As I indicated in an email last week, I will document cisco's basic
STUN functionality for the DLSw SIG effort.  It's been in the field now
for 2+ years and is used for PU4-to-PU2, PU4-to-PU4, and NT2.1-to-NT2.1.

Regards,
-----------
Wayne Clark
cisco Systems, Inc.
[email-masked]
415/688-4627